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1  Introduction 

TenIS  [1]  is  a  machine-independent  intermediate  language  which  has  been  developed  at 
RSRE  to  meet  a  wide  variety  of  programming  requirements;  in  particular  it  offers  a  high 
degree  of  integrity.  Owing  to  a  change  of  emphasis,  the  TenlS  programme  has  presently  been 
discontinued.  Instead,  effort  has  been  directed  towards  TDF,  a  machine-independent 
representation  of  program  developed  from  the  TenIS  code  interface. 

This  memorandum  is  intended  as  a  reference  for  future  work  programmes  which  research 
into  some  or  all  of  the  problems  addressed  by  TenIS.  It  describes  the  state  reached  by  the 
TenIS  project  and  attempts  to  highlight  those  areas  still  under  debate,  and  to  discuss  the 
options  for  compromise  and  removal  of  perceived  deficiencies. 

The  constraints  atvl  opportuiUties  for  evolution  of  TenIS  are  outlined  in  order  to  extend  its 
applicabiUty,  both  for  a  wider  range  of  programming  styles  and  for  a  wider  range  of  machine 
architectures.  The  need  for  evolution  is  particularly  nnarked  with  respect  to  TenIS  support  for 
program  analysis  and  parallel  architectures. 

The  design  goals  of  TenIS  and  its  relationship  with  TDF  are  described  in  §3.  §4  outlines  the 
state  of  TenIS  at  the  point  of  its  abandonment,  and  §5  contains  detailed  discussion  on  a 
number  of  aspects  of  TenIS  to  highlight  perceived  deficiencies  and  possible  paths  of  progress. 
These  latter  two  sections  have  been  taken  more  or  less  verbatim  from  a  paper  originally 
prepared  for  the  lED  COOTS  project,  described  in  §2,  apart  fiom  deletion  of  material 
concerned  only  with  the  COOTS  work  programme,  and  minor  changes  which  are  alterations 
to  the  modal  form  of  the  exposition  rather  than  the  content. 


2  The  COOTS  project 

TenIS  evolution  has  been  under  consideration  at  RSRE  for  a  number  of  tasks,  but  in 
particular  as  part  of  the  DTI  IED3/1  /1059  COOTS  collaboration,  in  which  RSRE,  University 
College  London,  and  Harlequin  Ltd  are  investigating  design  and  support  for  object-oriented 
programming  languages  and  environments  for  MIMD  parallel  machines.  As  part  of  the  RSRE 
eff  ort  TenIS  would  have  hvcn  compared  with  other  implementation  techniques;  TDF  has  now 
been  substituted  in  this  role.  The  TenIS  work  performed  under  COOTS  is  described  in  [2]. 

In  the  first  phase  of  the  project  we  had  to  identify  the  extent  of  evolution  of  TenIS  needed  to 
provide  parallel  and  object-oriented  behaviour.  In  September  1990,  therefore,  we  prepared  a 
working  paper  exploring  its  prosp>ective  developments.  This  described  the  state  of 
development  of  TenIS  as  it  existed  at  that  time,  and  how  it  had  to  be  enhanced,  both  for 
COOTS  and  more  generally.  The  majority  of  the  content  of  the  present  document  is  taken 
from  that  working  paper. 


3  TenIS  and  TDF 

TenIS  is  an  algebraically  defined  abstract  machine,  designed  to  provide  a  formal,  integrity- 
preserving,  yet  flexible  and  efficient  framework,  within  which  a  wide  variety  of  software 
engineering  problenu  can  be  addressed.  One  of  its  major  uses  is  as  a  common  intermediate 
language  ^tween  different  programming  languages  and  computing  hardwares,  with  high 
level  support  for  program  composition  and  efficient  interworldng.  The  efikietrey  problems 
that  have  bedevilled  previous  attempts  at  universal  intermediate  languages  are  overcome 
here  by  retention  of  typing  aird  high  level  constructs.  TenIS  is  strongly  typed,  with  a  uidform 
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type  system  that  embraces  a  wide  variety  of  high-level  languages,  together  with  types  more 
traditionally  appropriate  to  operating  system  functions.  Dynamic  type  checking  is  also 
supported,  but  it  is  the  static  type  checking  for  strongly  typed  languages  that  provides 
efficiency.  The  ability  to  choose  b^een  dynamic  and  static  typing  gives  the  greatest  scope 
for  combining  flexil^ity  with  efficiency. 

TenIS  code  is  converted  to  machine  code  through  a  trusted  translator  that  respects  the  type 
rules  and  other  aenuntic  properties  of  the  TeniS  formalism.  To  maintain  integrity  over  the 
whole  system  a  TeniS  rtuchine  comes  with  a  user  envirormtent  which  provides  support  for 
progtammittg  attd  system  services.  These  system  services  are  themselves  written  in  TeniS, 
via  the  exterrded  type  rtrechanism.  Vfithin  die  environment  one  can  construct  and  execute 
pieces  of  TeniS  but  nothing  else.  Thus,  provided  the  translator  is  correct  the  system  caimot  be 
perverted  and  its  integrity  is  preserved. 

A  few  years  ago,  a  machine-independent  code  interface  was  intnxluced  to  simplify 
implementation  of  TeniS.  This  has  since  been  developed  into  TDF  [3],  which  has  found 
application  as  an  intermediate  representation  for  a  variety  of  programming  languages.  At  a 
lower  level  than  TeniS,  it  addresses  questions  of  language  neutrality  and  code  generation 
more  directly.  Unlike  TeniS  it  does  not  exhibit  strong  typing  or  data  integrity,  nor  does  it 
contain  explicit  OS  structures  or  attempt  to  be  a  complete  system  in  its  own  right. 

The  twin  aims  of  flexibility  and  efficiency,  within  the  constraints  of  formality  and  consistency 
enforcement,  parbcularly  at  the  system  level,  have  naturally  led  to  certain  compromises  and 
pragmatic  decision  taking  in  the  design  of  TeniS.  These  compromises  and  decisions  need  to 
be  questioned  both  when  considering  how  to  develop  the  formality,  and  when  considering  its 
breadth  of  applicability.  The  presence  of  TDF  presents  an  opportunity  to  refocus  TeniS  mote 
directly  on  these  integrity  and  system  aspects,  with  code  generation  and  language  neutrality 
being  downgraded  to  a  certain  extent. 

Earlier  this  year  further  work  on  TeniS  in  its  present  form  was  abandoned,  and  much 
software  was  left  in  an  incomplete  state.  However  many  of  its  design  goals  ate  still  valid  and 
may  be  addressed  by  similar  projects  in  future.  It  is  therefore  important  to  preserve  the 
intellectual  effort  already  put  into  ffie  project,  in  such  areas  as  the  means  of  construction,  the 
principles  underlying  the  type  system,  integrity  considerations,  and  the  mainstote  memory 
model. 


4  State  of  Tenl 5  development 

4.1  TeniS  versions 

The  present  definition  of  Tenl  5,  used  in  the  VAX  system  and  by  existing  compilers  and 
translators,  is  known  as  Version  0  (4],  15).  An  extension  has  been  defined,  called  VO-p,  which 
has  added  features  for  pseudoparaUelism.  VO-p  was  the  original  baseline  for  the  CDOT5 
project^. 


t  The  Vtnion  0  bneline: 

Difinitton  of  Mouential  VO  —  eomplde 
VAX  truieUlor  for  VO  —  oompidc 

Expartancnul  kcnwi  and  lyMin  for  VO  ninning  on  VAX  —  almoai  complete 
Definition  of  pteudoparalW  extentfant  for  VO-p  —  oompleie 
Extension  of  VAX  kemd  forVOp  —  incomplete 
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A  paper  definition.  Version  1,  irons  out  oddities  in  the  TenIS  operations  and  has  some  extra 
functional  power.  In  particular,  in  VI  there  is  a  more  fluent  model  of  integer  aritlunetic, 
mainstore  memory  can  be  addressed  at  finer  granularity,  arul  complex  operations  such  as 
case-union  have  a  cleaner  serruintic  basis.  One  improvement  is  that  many  operations  have  an 
additional  form  that,  on  detecting  an  error,  bratKhes  rather  than  raising  an  exception.  VI  is 
far  from  perfect,  but  it  is  not  interrded  that  any  further  work  wiU  be  dotre  on  it.  VI  has  a 
pseudoparallel  extension  VI -p,  which  corresponds  directly  to  VO-p. 

Ten15  Version  2  is  a  postulated  definition  which  will  have  a  much  mote  rigorous  semantic 
basis,  aimed  at  achieving  greater  extensibUity  atrd  ease  of  trarrsformation.  It  may  be  that 
several  iterations  will  be  needed  before  we  reach  our  ultimate  goal.  Much  of  the  research 
needed  for  its  definition  is  continuing. 

4.2  The  demonstration  system 

The  demonstration  system  is  essentially  an  updated  and  improved  version  of  the 
environment  written  for  the  RSRE  FLEX  capability  architecture  [6],  trarrsferred  into  a  Ten!  5 
framework.  The  first  prototype  system  has  been  implemented  on  VAX  using  VMS  and 
DEC  windows,  and  was  in  the  final  stages  of  development  at  the  point  of  abandonttrent.  It  is 
anticipated  that  this  system  should  port  easily  to  other  uniprocessor  implementations,  given 
appropriate  device  drivers. 

The  user-interface  to  the  system  is  an  extensible  integrated  editor.  Rather  than  having 
commands  and  files  in  the  conventional  sense,  a  different,  very  flexible,  style  is  presented. 
The  emphasis  is  on  construction  and  combirution  of  values,  where  any  operadotrs  that  are 
valid  on  a  value  may  be  performed,  giving  uiranticipated  use  of  program  and  data. 

Within  this  environment  there  is  great  potential  for  program  development.  Documents  are 
just  another  kind  of  value,  and  may  have  arbitrary  values  embedded  within  them  in  addition 
to  text,  which  can  itself  be  structured  in  a  variety  of  ways.  A  compiler  is  just  a  program  that 
takes  such  a  document  as  its  input,  either  producing  the  compiled  result  or  highlighting  any 
rrustakes.  A  module  is  an  updateable  value  that  contains  a  compiled  unit.  The  module  system 
tracks  depetKiencies  between  modules  aird  can  automatically  provide  minimal  recompilation 
to  eirsure  that  they  are  kept  coirsistent  when  components  are  altered.  Compilers  exist  for  a 
variety  of  languages,  itKluding  Algol68,  Pascal,  Standard  ML  and  a  notation  specially 
designed  for  TenlS.  If  a  program  fails,  then  the  resulting  exception  value  can  be  diagnosed, 
enabling  the  values  known  to  the  program  at  that  time  to  be  examined  and,  of  course, 
operated  on  in  any  way  the  user  sees  fit. 

The  current  situation  is  that  we  can  traiufer  ffagments  of  TenIS  to  the  VAX  and  translate  and 
run  them  there.  We  do  not  have  a  h  Hy  usable  TenIS-based  operating  envirorunent  available 
for  general  use,  though  many  of  t  e  comportents  ate  itrdividually  working,  such  as  the 
evaluation  and  examination  fadlitics,  and  the  prersistent  filestore.  The  trujor  unfittished 
components  are  the  notation  compiler  atxi  the  module  system;  major  problems  have  been 
etKOuntered  in  bootstrapping  this  software.  Whilst  the  envirorunent  is  of  sigttificant  value,  it 
cannot  be  considered  a  true  demonstration  of  the  power  of  TenIS  without  full  support  for 
these  features,  or  while  it  is  based  upon  Version  0. 

4.3  Enhancement  and  upgrading 

Unforeseen  future  developments  will  change  TenIS  systems  in  their  breadth  of  appUcability 
atrd  semantic  basis.  TenIS  must  therefore  be  capable  of  evolution  and  extetrsion.  When 
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extending  Ten  15,  for  example  to  accommodate  a  new  kind  of  computer  architecture  or 
programming  paradigm,  care  will  always  have  to  be  taken  that  unifonnity  is  preserved  as  far 
as  possible.  There  is  the  risk  of  complicating  the  semantics  or  compromising  the  integrity  of 
TenlS  which  previously  existed,  f^r  example,  VO-p  tasks  introduce  the  requirement  of 
atomicity  in  u^ating  shared  memory.  The  intent  of  the  Version  2  basis,  which  places  greater 
emphasis  on  formal  semantics,  is  to  encourage  unification  rather  than  complication. 


5  Aspects  of  TenlS 

This  section  presents  an  overview  of  various  aspects  of  the  TenlS  world,  with  particular 
reference  to  their  perceived  deficiencies.  Sorrte  deficiertdes  are  of  irtinor  impact;  for  others  any 
solution  would  demand  urxlue  effort  or  seriously  compromise  some  other  aspect  of  TenlS. 

Associated  with  each  aspect  is  a  list  of  work  items  to  correct  the  deficiency.  No  attempt  is 
made  in  this  paper  to  categorise  them  in  importance  or  complexity'^.  Many  items  are 
incidental,  but  some,  especially  those  intrinsic  to  Version  2  research  and  the  memory  model, 
are  central  to  future  development  and  involve  studying  a  great  deal  of  theory,  arxl  so  must  be 
considered  a  high  risk.  Very  little  of  the  propos^  work  has  ever  been  done.  Indeed  the 
expectation  that  even  the  minimal  developments  discussed  would  be  beyond  the  resources 
available  was  one  reason  for  discontinuing  TenlS  as  it  stood. 

5.1  Method  of  definition 

TenlS  has  been  defirred  as  an  algebraic  sigruiture.  It  is  the  target,  arui  sometimes  also  the 
source,  for  programs  which  produce  other  programs,  such  as  compilers,  simulators  and 
optimisers.  Apart  from  Pascal  and  Algol68  compilers  we  have  hardly  demorutrated  its  power 
in  this  respect;  SID  [7]  is  one  tool  which  could  be  retargetted  at  Tenl  5.  To  operate  on  a  piece  of 
TenlS,  to  use  it  as  a  source  for  a  trarrsformation,  one  constructs  a  homomorphism  over  the 
signature;  that  is,  a  set  of  srruill  operatioru,  one  for  each  constructor  of  the  signature,  from 
which  the  complete  trartsform  gets  built  automatically.  Examples  iiKlude  pretty  printers, 
encodings  formatted  for  disc,  and  the  translator  itself.  At  the  moment  few  such  tools  have 
been  built,  so  we  do  not  yet  know  their  potential  —  perhaps  the  best  model  is  the  VAX 
translator.  The  schema  for  producing  homomorphisms  has  to  be  delineated  better.  David 
Bruce  has  developed  a  prop)er  model  for  such  trar^ormations,  initially  for  a  trarrslator  for  the 
transputer,  which,  given  a  set  of  functions  to  decompose  one  concrete  representation  and  a 
set  of  erKoding  routines  to  construct  another,  will  generate  a  homorrwrphism  automatically. 

Much  work  rerrrairvs  to  be  done  on  the  mathematics  underlying  the  TenlS  algebraic 
definition.  It  is  largely  independent  of  the  outside  world,  apart  from  the  introduction  of 
formal  tokeru  and  primitive  rrotions  like  integers  and  strings.  However;  the  semantics  are 
described  almost  entirely  in  English.  To  use  TenlS  as  a  formal  basis  for  prograrruning  they 
must  be  expressed  formally.  We  expect  the  semantics  of  V2  will  be  so  defirved.  Fmding  a  basis 
for  V2  has  turned  out  to  be  much  harder  than  expected.  For  example,  the  semantics  a^  result 
type  of  the  field  selection  operator  are  dependent  upon  the  value  of  an  integer  parameter. 
PiWent  lines  of  research  have  recently  taken  us  into  lambda-calculus,  functional 
prograrruning  and  Martin-Ldf's  intuitionistic  type  theory. 

Should  this  research  yield  fruit  there  would  be  a  large  qualitative  increase  in  the  means  of 
corutruction  of  TenlS.  Essentially  TenlS  would  be  self-representable,  in  the  serrse  that  we 


t  Atpwitniad  bi  the  original  working  paper;  the  work  hems  alao  contained  an  analyai*  of  their  lelevance  to  the 
COOTS  project. 
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could  build  a  type  system  sufficiently  powerful  to  allow  construction  only  of  correct  Tenl5.  It 
would  be  easy  to  extend  a  TenlS  defined  thus,  and  to  produce  difierent  variants  tailored  to 
different  machine  characteristics.  Features  which  are  presently  incorporated  in  an  ad-hoc 
manner,  like  polymorphism,  concurrency  and  ADTs,  could  be  defined  naturally.  As  a  further 
benefit,  the  improvement  of  the  semantk  basis  would  facilitate  the  automated  production 
and  verification  of  tools  such  as  interpreters  aikd  translators. 

Work  items: 

demonstrate  algebraic  construction  of  TenlS  by  programs 
demonstrate  transformation  of  TenlS  to  a  homomorphic  image 
Version  2  research 

5.2  The  translator 

The  translator  is  the  program  that  produces  directly  executable  nnachine  code  correspxtnding 
to  its  TenlS  input.  It  is  distinguished  in  that  it  is  the  only  program  that  has  the  ability  to 
produce  such  code.  The  trust  in  a  TenlS  system  resides  solely  in  the  translator,  or 
equivalently,  it  is  the  only  program  that  is  permitted  to  break  the  integrity  of  the  TenlS 
machine,  as  expressed  by  the  typ>e  system.  Whilst  we  do  not  beUeve  the  translator  can  be 
formally  proven  as  yet,  we  consider  that  the  homomorphic  form  of  construction  will  aid 
greatly  in  avoiding  errors. 

In  the  context  of  V2  it  might  be  better  to  consider  whether  a  symbolic  interpreter  is  a  more 
important  program.  An  interpreter  would  yield  the  true  op>erational  semantics  of  TenlS  and 
overcome  the  mental  distinction  between  compilation  time  and  run  time.  There  are  also 
several  methods  of  automatically  generating  a  full  translator  directly  from  such  an 
interpreter. 

Work  items; 

demonstrate  trustworthiness  of  translator 
write  an  interpreter 

5.3  The  type  system 

Underpinning  all  program  and  data  within  a  TenlS  system  there  is  a  strong  typ>e  system.  Each 
fragment  of  TenlS  program  delivers  a  value;  the  only  appUcable  operations  are  those 
appropriate  to  its  tyjre,  which  is  a  homomorphic  image  derivable  in  finite  time.  The  available 
operatioits  thus  define  the  functionality  of  the  system;  by  choosing  them  carefully  we  have 
achieved  full  data  integrity,  in  the  sense  that  no  value  can  be  treated  as  having  a  type 
incompatible  with  the  one  it  had  when  it  was  first  created.  The  trartslator  guarantees  this  by 
rejecting  any  TenlS  that  does  not  statically  conform  to  this  type  regime.  With  V2  the  type 
system  will  become  even  more  powerful,  and  will  demand  especial  attention  to  its 
implementation. 

It  is  important  for  several  reasons  that  the  type  system  and  primitive  operatioits  should  be 
independent  of  specific  machine  characteristics.  First,  the  correctness  of  a  TenlS  program  is 
determined  by  type,  and  it  would  be  quite  unsatisfactory  if  programs  were  deeined  correct 
on  one  machine,  but  not  on  aixither.  For  example,  in  VO  the  bounds  of  integer  types  are 
limited  by  implementation  limits  (usually  the  machine  word  length),  and  this  is  reflected  in 
the  types  of  some  operations.  A  program  that  is  type-correct  for  one  machine  may  therefore 
be  type-incorrect  for  one  having  difierent  word  len^h;  this  is  clearly  an  unacceptable  state  of 
affairs. 
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Second,  it  should  be  feasible  to  write  programs  that  are  truly  portable,  in  the  sense  that  their 
run-time  behaviour  will  be  the  same  on  any  implementation,  in  both  VO  and  VI,  for  example, 
equality  is  defined  as  equality  of  representation,  so  that  it  is  extremely  difBcult,  if  not 
impossible,  to  reason  formally  about  the  behaviour  of  the  program.  Qearly,  some  physical 
resource  limits,  such  as  the  amount  of  available  store,  cannot  be  completely  avoided,  but  it 
might  be  questioned  what,  if  any,  machine-given  limits  are  acceptable.  When,  for  example, 
the  limits  of  bounded  integers  are  constrained  by  the  implementation,  numeric  overflow 
might  occur  on  one  machine  but  not  on  one  having  larger  word  length,  even  though  their 
types  are  the  same.  Obviously,  the  presence  of  non-determiiusm  in  a  parallel  system  means 
that  we  caniiot  sp)ecify  a  single  behaviour.  Instead,  it  is  essential  that  we  can  reason  setuibly 
about  non-determiiusm,  for  example,  to  demonstrate  that  its  presence  is  benign. 

Third,  the  type  system  places  implicit  comtraints  on  an  implementation,  and  we  should  not 
casually  prescrite  any  particular  representation  of  its  values  that  nught  prove  grv.  .ly 
unsuitable  for  some  architectures,  thus  condeiiming  them  to  poor  efficiency.  One  requirement 
that  is  technically  essential  is  that  if  one  type  can  be  coerced  to  another,  then  corresponding 
values  of  the  two  types  must  both  have  the  same  representation.  Another,  this  time  somewhat 
spurious,  requirement  is  that  integers  are  virtually  required  to  be  two's  complement. 

The  types  of  the  system  have  been  chosen  at  quite  a  fine  granularity  to  allow  efficient 
physical  representation  and  coding  of  operations,  but  not  at  the  cost  of  inordinate  compile¬ 
time  complexity.  For  example,  integer  subranges  have  been  incorporated,  but  not  sub^ts. 
The  system  also  extends  beyotul  the  types  normally  found  in  programming  languages  to 
describe  features  that  are  traditioruilly  associated  with  operating  systems.  Other  type 
primitives,  the  array  for  example,  are  quite  high-level,  and  could  be  expressed  as  an  abstract 
data  type.  However,  the  operatioiu  on  an  ADT  might  not  always  be  as  efficient  as  those  on  a 
built  in  primitive. 

There  is  also  the  pragmatic  concern  that  run-time  overheads  due  to  the  advanced  features  of 
Ten15,  such  as  fost-ciass  procedures  and  garbage  collection,  should  not  be  too  high  for 
programs  that  do  not  use  them  —  including  all  those  derived  from  languages  such  as  Ada, 
Pascal,  etc.  This  has  influenced  the  level  of  data-abstraction  so  that,  for  example,  standard 
integer  arithmetic  is  defined  to  be  bounded,  with  an  overflow  exception  if  the  machine  word 
length  is  exceeded,  rather  than  making  all  integers  unlimited. 

TenlS  must  also  be  able  to  support  several  forms  of  polymorphism,  both  on  their  own  merits 
and  to  meet  the  lequirements  of  modem  functional  languages  and  object  systems.  No  direct 
support  for  ad-hoc  variants  such  as  overloading  are  provided,  as  they  are  syntactic  niceties 
that  compilers  should  deal  with  before  generating  TenlS.  The  present  type  system  includes 
universal  quantification,  so  that  algorithms  can  be  abstract^  away  from  unnecessarily 
concrete  instances;  existential  quantification,  which  can  be  used  to  built  ADls  and  objects; 
and  some  measure  of  subtyping  (i.e.,  bounded  polymorphism),  providing  a  way  of  tackling 
some  forms  of  inheritance.  These  features  have  been  added  into  TenlS  over  time,  in  a 
somewhat  haphazard  manner.  We  would  like  to  treat  this  area  more  imiformly  in  future,  and 
are  itot  yet  certain  of  the  theoretical  bounds  to  higher-order  typing.  It  is  an  important  part  of 
the  research  for  Version  2  TenlS. 

A  particular  problem  is  that  no  values  in  the  system  can  be  treated  in  a  completely 
polymorphic  way,  in  that  they  cannot  be  regarded  as  having  completely  unknown  type. 
Polymorphism  is  restricted  to  the  contents  of  constructs  of  known  size,  such  as  pointers.  This 
is  b^use  the  size  of  each  value  must  be  known  at  compilation  time,  in  older  that  sufficient 
space  can  be  allocated  to  hold  it.  Recently  the  concept  of  'normalization'  to  a  fixed  size  has 
been  introduced,  with  the  intention  that  this  wiU  eventually  be  the  only  fixed  size  value. 
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Unfortunately,  such  normalization  tends  to  pervade  the  whole  program,  and  there  are  severe 
interoperability  problems  between  the  non*normalized  and  the  normalized  worlds.  The 
alternative,  of  implicitly  normalizing  every  value  (as  in  ML,  Lisp  and  fuivrtional  languages), 
is  considered  by  some  as  contrary  to  the  spirit  of  fine  granularity;  it  may  also  be  slightly  less 
efficient. 

Work  items: 

representation-independent  semantics  for  equality,  integer  types,  etc. 
coitsider  granularity  and  breadth  of  scope  of  the  type  system 
implement  efficient  algorithms  to  marupulate  V2  types 
decide  whether  every  value  should  be  implicitly  normalized 

5.4  Cyclic  structures 

For  integrity  reasons,  every  declaration  and  memory  allocation  must  be  properly  initialised 
with  a  value  of  the  appropriate  type.  This  can,  however,  cause  difficulties  with  cyclic 
structures,  where  the  item  being  constructed  is  needed  in  order  to  construct  itself!  There  are 
some  tightly  cyclic  types  for  which  there  is  no  satisfactory  means  of  creating  any  suitable 
values  at  all.  We  need  to  develop  a  general  model  that  will  adequately  address  this  problem, 
since  these  types  are  otherwise  pterfectly  reasonable,  and  occasionally  prove  rather  useful. 

In  VO  there  is  an  operator,  parameterised  by  a  type,  which  creates  a  valid  value  of  that  type, 
thus  solving  the  immediate  problem.  Unfortuirately,  we  know  that  this  is  not  a  good 
solution  —  especially  since,  in  the  more  powerful  ty^  systems  we  are  interested  in  for  V2, 
the  existence  of  such  values  is  undecidable.  There  is  also  a  special  mechanism  for  the  most 
important  class  of  cyclic  structures,  namely  mutually  recursive  procedures,  but  again  this  is 
not  a  long  term  solution.  Many  functiortal  languages  allow  totally  general  recursive 
equations,  but  usually  achieve  this  via  lazy  evaluation,  a  technique  which  is,  alas,  not  without 
its  limitatiorts.  Other  languages  have  evaded  the  problem  by  placing  strong  syntactic 
restrictions  on  the  construction  of  recursive  structures. 

Work  item: 

find  method  of  constructing  general  cyclic  data 

5.5  Procedure  closures 

One  kind  of  data  value  in  Tenl5  is  the  procedure  closure,  where  a  block  of  code  is  bound  to 
non-local  data.  This  is  very  important  since  we  need  it  to  build  systems.  The  ion  is  a 
generalisation  of  procedure  that  has  multiple  binding  times.  Procedures  and  ions  are  first- 
class  values  just  as  scalars  and  vectors  are;  they  can  likewise  be  building  blocks  in  compiosing 
other  values.  The  procedure  is  the  unit  of  program  in  Ten!  5  —  it  cannot  be  broken  down  to 
reveal  the  code  and  non-locals  from  which  it  was  constructed,  but  only  appbed  to  arguments 
to  deliver  a  result.  Thus,  access  to  non-lcxab  can  be  strictly  controUed,  and  is  the  prime 
means  of  achieving  data  security  (as  opposed  to  integrity)  in  Ten15;  for  example,  secure 
communication  can  be  implemented  using  a  private  non-local  as  a  channel. 

We  can  identify  several  subclasses  of  procedure  which  have  particularly  simple  or  useful 
analytic  properties,  such  as  separability  (no  non-locab  accessible  from  another  procedure), 
monomorphbm,  referential  transparency.  No  such  cbss  has  been  formally  identified  in 
Ten15.  Other  properties  of  a  procedure  concern  whether  it  b  suitable  for  special  methods  of 
compilation;  for  example,  removing  tail  recursion,  or  treating  as  a  simple  subroutine.  These 
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are  essentially  compiler  optimisatioru  (concerned  with  such  details  as  the  form  of  the 
procedure  body  or  the  lifetimes  of  local  artd  non-local  values)  rather  than  an  analytic  featiue. 

Work  items: 

need  for  multiple  binding  times 
consider  level  of  data  security 
analysis  of  non-locals  for  shared  variables 
static  analysis  to  find  other  properties 

5.6  Interactive  working 

We  envisage  working  in  a  uitiform  world  where  the  distinction  between  systems  and 
applications  progratT\s  is  blurred  and  any  value  can  be  created  and  used  freely  arvi  in  an 
uiuinticipated  manner  throughout  the  environment.  We  believe  that  Ten15  could  be  used  to 
build  such  an  advanced  human-computer  interface.  Key  features  of  an  implementation  are  a 
flexible  command  interpreter  capable  of  producing  any  desired  Tenl5  fragment,  and  the  type 
'typed^  a  packaging  of  a  value  with  its  type,  suitable  for  use  with  the  interpreter.  The 
command  interpreter  has  the  same  integrity  as  preprogrammed  Tenl5  in  that  no  operation 
can  be  incorrectly  applied. 

The  FLEX  editor  and  command  interpreter  [81  together  display  these  precepts,  but  in  a 
largely  untyped  domain.  Further  study  is  required  into  their  realisation  within  a  statically 
typed  framework,  and  also  into  the  functionality  of  the  command  interpreter.  In  the 
demonstration  system,  the  command  interpreter,  TRUC,  is  quite  primitive  in  that  it  does  not 
provide  the  full  power  of  the  TenlS  machine,  and  the  type  system  is  overridden,  although  in 
a  controlled  manner,  when  loading  modules. 

Work  item: 

C0T«ider  functional  power  of  command  interpreter 

5.7  Diagnostics 

On  FLEX  we  have  a  post-mortem  debugger  which  can  relate  values  in  the  workspaces  of 
failed  procedures  back  to  source  text.  This  tool  can  easily  be  adapted  for  any  single-process 
TenlS  system.  In  the  longer  term  we  would  like  an  interactive  debugger,  particularly  when 
multiprocessing.  Interpretation  is  one  possible  approach,  but  often  it  is  desirable  or  even 
necessary  to  work  with  code  more  closely  resembling  the  normal  compiled  output.  To 
develop  a  good  debugger  we  would  have  to  formalise  the  notion  of  break  points  in  TenlS  and 
consider  carefully  the  consequences  for  data  security.  Useful  visualisation  of  the  confusing 
amount  of  data  available  in  a  fully  parallel  system  will  also  need  much  work. 

Work  itenns: 

write  an  interactive  debugger 

devise  methods  of  debugging  distributed  TenlS 

5.8  Memory  model 

The  model  of  memory  presented  by  TenlS  is  based  on  the  allocation,  on  demand,  of  an 
amount  of  memory  sufficient  to  contain  a  value  of  some  particiolar  type.  Such  allocation 
deliver  a  pointer  value  that  allows  access  to  that  region  of  store;  such  pointers  cannot  be 
forged,  and  integrity  requirements  mean  that  primitive  concepts  such  as  'address'  do  not 
play  a  part. 
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There  is  no  explicit  retum-to-free  of)eration  (it  would  be  neither  souikI,  complete  nor 
desirable),  so  for  all  practical  purposes  some  kind  of  garbage  collector  is  required  in  order  to 
recycle  iiuccessible  storage.  There  is  still  the  problem  of  what  to  do  when  there  really  isn't 
enough  store  available.  On  FLEX  the  requesting  process  is  failed  —  this  is  an  unsatisfactory 
heuristic  that  takes  no  account  of  how  much  memory  any  individual  process  uses  and  rarely 
yields  useful  diagnostics.  (Worse  still,  if  the  process  forms  a  vital  part  of  the  system  the 
consequences  are  usually  disastrous!) 

Sequential  Ten15  does  already  admit  of  more  than  one  store,  though  to  date  this  aspect  has 
been  treated  in  a  somewhat  ad-hoc  foshion.  There  is  a  single  maiitstore,  which  is  used  to  hold 
the  contents  of  pointers,  vectors  or  arrays,  together  with  any  working  space  that  an 
implementation  may  need.  There  may  also  be  several  persistent  datastores,  which  provide 
permanent  disc  storage.  Parallel  versions  of  TenIS  will  also  have  to  allow  for  the  preset«ce  of 
multiple  memories,  and  coitsider  the  consequences  of  sharing  a  single  store  between  several 
processors.  The  operations  on  these  different  kittds  of  stores  are  significantly  different.  We 
need  to  produce  coherent  models  of  these  kinds  of  stores,  especially  in  a  parallel  system 
where  many  mamstores  may  exist,  and  consider  whether  these  models  can  and  should  be 
unified. 

In  safety-critical  and  other  applications  it  is  important  that  memory  is  not  dyiramically 
allocated,  or  at  least  that  it  is  known  precisely  how  much  heap  is  needed.  We  would  like  to 
identify  a  static  subset  of  Tenl5.  We  believe  that  the  operations  which  demand  heap 
allocation  can  be  identified. 

Work  iterrts: 

out  of  memory  exceptions 

develop  alternative  memory  models  and  coirsider  their  unification'^ 
static  subsets  of  Tenl5 

5,9  Mainstore 

The  mainstore  in  TenlS  can  be  considered  as  serving  two  nuijor  purposes.  Most  obviously,  the 
contents  of  pointers,  vectors  and  arrays  are  kept  here,  allowing  for  mutability,  aliassing,  etc. 
In  addition,  it  is  used  by  an  implementation  as  a  working  store,  to  represent  values  that  do 
not  formally  reside  in  memory,  such  as  types,  and  in  order  to  realize  implicit  concepts  such  as 
procedure  workspaces.  The  mainstore  is  not  modelled  as  a  separate  store,  but  is  assumed  to 
be  closely  attach^  to  some  processor,  which  performs  operations  on  it. 

There  is  a  compromise  to  be  found  between  the  iteed  for  dynamic  management  of  memory 
and  the  goal  of  program  efficiency.  In  particular,  the  garbage  collection  overhead  should  not 
be  intrusive,  especially  during  highly  interactive  activities,  such  as  editing.  The  garbage 
collector  is  currently  implemented  as  a  variant  of  the  mark/sweep  algorithm,  which  is  linear 
in  all  of  its  parameters;  the  translator  ensures  that  the  run-time  representations  used  are  such 
that  scalars  and  non-scalars  may  be  readily  distinguished.  A  number  of  well-known 
techniques  are  used  to  reduce  the  amount  of  memory  allocated,  and  hence  the  frequency  of 
collection.  Despite  these  efforts  there  is  a  noticeable  interruption  of  processing  during 
garbage  collection  (a  second  or  so  on  FLEX),  and  with  larger  memories  the  interruption  could 
easily  become  intolerable. 

Work  item; 

consider  on-the-fly  garbage  collection 


f  Initial  work  on  this  topic  may  be  found  in  |9|. 
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S.lOMultiple  and  shared  memories 

V^^th  the  introduction  of  parallelism  into  Tenl  5  we  have  to  consider  the  consequences  of 
sharing  a  single  store  between  several  processors,  and  allow  for  the  presence  of  multiple 
memories.  Processes  can  interact  only  by  explicitly  communicating  some  value  or  by  causing 
side-effects  on  some  data-stmcture  tlut  has  previously  been  transmitted. 

Within  a  single  memory,  arbitrarily  complex  values  can  be  communicated  with  essentiaUy 
infinite  bandwidth  by  passing  pointers  or  side-effecting.  Transfers  from  one  store  to  another 
generally  involves  some  physical  link  of  limited  bandwidth,  so  there  are  significant  efficiency 
differences. 

Communication  between  distributed  memories  leads  to  an  important  semantic  distinction,  in 
that  transferring  a  value  in  the  same  store  results  in  sharing  of  the  same  value,  whereas 
transferring  to  another  store  yields  only  an  isomorphic  copy  (which  preserves  sharing  and 
circularities  within  the  value  itself,  but  not  with  other  values).  Other  significant  differences 
can  result  from  the  transient  nature  of  some  kinds  of  value,  or  their  implicit  binding  to  one 
particular  location.  Device  drivers,  for  example,  are  obviously  attach^  to  some  physical 
entity.  Because  of  the  change  of  semantics  involved,  it  may  not  always  be  appropriate  to 
transfer  such  values  between  memory  spaces.  For  each  such  kind  of  value,  an  ad-hoc  decision 
has  been  taken  whether  to  allow  the  transfer,  with  its  change  of  meaning,  or  to  forbid  it.  It  is 
not  always  possible  to  predict  whether  any  particular  value  will  be  transferrable,  due  to 
abstractions  such  as  procedure  non-locals,  so  that  dynamic  tests  are  needed. 

Properties  that  are  true  on  a  uniprocessor  can  not  always  be  assumed  to  hold  when  more  than 
one  processor  shares  direct  access  to  a  memory.  The  b«st  sequential  algorithms  are  often  not 
the  most  appropriate  techniques  when  several  processors  can  access  the  memory 
simultaneously.  For  example,  the  correctness  of  many  garbage  collection  algorithms  depends 
on  the  store  not  being  altered  whilst  they  are  working.  Co-operative  scheduling  on  a  single 
individual  processor  is  often  enough  to  ensure  atomicity  of  critical  functions,  but  the  store  of 
a  shared-memory  machine  is  accessed  as  if  the  scheduling  were  pre-emptive. 

On  the  other  hand,  there  are  some  hard  problems  associated  with  distributed  memories. 
Before  complex  values  can  be  communicate  between  stores,  they  may  have  to  be  'flattened' 
to  fit  through  the  physical  links  joining  them,  and  reconstructed  at  the  other  end;  this  is 
automatically  done  by  the  Tenl  5  kernel.  If  a  system  is  homogeneous  (i.e.,  scalar  data  has  the 
same  representation  everywhere),  and  the  same  translator  resides  on  each  node,  then  the  data 
can  be  sent  directly  as  described.  With  a  heterogeneous  network  only  untranslated  Tenl  5  can 
be  transmitted,  to  be  translated  either  at  the  remote  node  or  by  a  trusted  cross-translator  on 
the  host.  We  need  to  study  carefully  the  consequences  of  such  heterogeneity  on  the 
representations  we  can  use. 

Furthermore,  it  is  practically  essential  that  there  can  be  cross-store  pointers,  for  otherwise 
interaction  between  processes  residing  in  different  memories  is  nigh  impossible.  However, 
there  is  then  significant  difficulty  in  garbage  collection,  mostly  because  of  the  need  to 
preserve  values  that  are  only  referenced  from  a  remote  store.  It  is  also  useful  to  be  able  to 
perform  operations  on  values  stored  remotely;  the  most  important  class  is  to  be  able  to  invoke 
procedures  on  another  machine  with  some  kind  of  remote  procedure  call  (RPC)  mechanism. 
This  can  be  used  to  maintain  consistency  across  the  system  by  centralising  some  facility  at  a 
single  node. 
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Work  items: 

garbage  collection  of  shared  and  distributed  memory 

atomic  allocation  and  access  of  shared  and  distributed  memory 

parallel  on-the-fly  GC 

transfer  of  untransferrable  values 

heterogeneous  systems 

cross-store  pointers 

5.11  Persistent  datastores 

Ten15  splits  memory  into  two  levels;  volatile  mainstore  and  persistent  filestore  (datastores). 
In  contrast  to  mainstore,  there  is  an  explicit  model  of  datastore  as  an  entity  outside  the  main 
processing  unit,  be  it  a  Winchester  disc,  CD-ROM,  magnetic  tape  or  whatever.  There  is  no 
concept  of  ownership  of  a  datastore  —  any  CPU/mainstore  may  talk  to  any  number  of 
datastores.  Conversely,  datastore  values  cannot  refer  to  anything  in  mainstore,  nor,  at  the 
moment,  to  anything  on  other  datastores.  This  decoupling  reflects  that  datastores  have  facets 
greatly  different  from  mainstores:  they  can  be  detached,  they  hold  much  more  data,  but  in 
larger  granules,  this  data  is  persistent,  and  traffic  is  slow.  We  nevertheless  wish  to  preserve 
the  design  intent  of  TenIS  in  the  datastore  model  —  thus  datastore  values  can  have  almost 
any  type  and  their  integrity  cannot  be  corrupted.  To  simplify  this  latter  goal  present 
Implementations  of  datastores  are  non-overwriting.  Each  value  is  written  to  a  fresh  area  of 
the  store,  then  the  root  reference  updated  atomically.  This  simple  atomic  updating  model 
proved  inadequate  for  database  transactions,  and  a  mkhod  of  updating  several  disc  locations 
together,  called  transactioru,  has  been  added. 

Some  kinds  of  value  cannot  be  copied  onto  a  persistent  store  because  of  their  temf>oral 
namre;  for  example,  a  transaction  carmot  be  persisted,  then  resumed  at  a  later  date.  For  each 
such  kind  of  value,  an  ad-hoc  decision  has  been  taken  whether  to  allow  the  transfer,  with 
change  of  meaning,  or  to  forbid  it. 

There  are  optimisations  which  cut  down  on  datastore  traffic.  On  reading  a  value  into 
mainstore  it  is  effectively  cached  until  the  next  mainstore  garbage  collection,  thus  obviating 
any  reread  of  the  value. 

Datastore  garbage  collection  occurs  off  line,  when  the  store  is  full.  On-line  datastore  garbage 
collection  is  presently  precluded  by  inadequate  mainstore  resources.  Our  current  garbage 
collector  does  not  perform  compaction,  but  it  would  be  possible  to  compact  the  datastore 
without  corrupting  the  data. 

Work  itetits: 

persistence  of  unpersistable  values 
CTOss-datastore  pointers 
on-line  datastore  garbage  collection 

5.12  Parallelism  and  networking 

Ten15  VO-p  has  extertsions  for  pseudoparallelism,  but  does  not  explicitly  address  distribution 
of  program  and  data  to  remote  processors.  It  is  hoped  that  its  pseudoparallel  operations  will 
prove  suitable  for  use  within  a  truly  parallel  programming  environment.  To  map  programs 
aitd  data  onto  a  parallel  architecture,  extra  operations  cotKemed  with  distribution  remain  to 
be  defined  and  efficient  implementatiorrs  fot^. 


The  Evolution  of  Tenl  5 


Distribution  across  a  network  may  be  a  special  case  of  the  implementation  of  Tenl  5  on  a 
distributed  memory  multi-processor.  From  FLEX  we  have  experience  of  transmitting  data 
between  homogeneous  machines  connected  via  Ethernet,  and  of  using  RPC^. 

One  extra  problem  is  to  communicate  information  to  and  from  the  world  outside  Tenl  5.  To 
preserve  the  integrity  of  Tenl  5,  data  formatted  outside  must  either  be  sufficiently  primitive 
that  we  know  it  must  be  safe  (such  as  a  byte  stream),  or  it  has  to  be  trusted. 

Work  items: 

distribution  across  homogeneous  close-coupled  networks 
unification  of  loose  and  close-coupled  networks 
trustworthiness  of  data 
distribution  across  networks 

memory  allocation  and  garbage  collection  for  distributed  Tenl  5 

5.13  Programming  languages  and  TenlS 

The  main  use  to  date  of  TenlS  has  been  as  a  common  taiget  language  for  compilers.  Algol68 
and  Pascal  compilers  exist  for  VO,  one  for  Standand  ML  is  almost  complete,  and  one  for  Ada 
has  been  partiaUy  developed.  Full  mappings  from  Ada  to  VI  have  also  been  produced. 
Whilst  integrity  coi\straints  mean  that  unsafe  languages  such  as  C  are  not  suitable  sources,  it 
ought  in  principle  to  be  possible  to  compile  any  strongly  typ>ed  language  to  TenlS.  However, 
a  few  language  features,  such  as  the  first<lass  continuations  found  in  Scheme,  are  not  well 
supported  and  may  cause  implementations  to  be  rather  inefficient.  An  important  part  of  our 
research  will  be  to  evolve  so  that  such  features  can  be  realistically  provided. 

On  the  other  hand,  it  is  not  possible  to  obtain  the  full  power  of  TenlS  by  compilation  from 
existing  languages.  An  'assembler'  is  required  so  that  we  can  create  any  specific  fragment  of 
TenlS,  which  can  then  be  combined  with  the  output  of  other  compilers.  The  irotation  that 
originally  produced  these  small  fragments  has  since  evolved  into  a  substantial  programming 
language  in  its  own  right.  The  success  of  Tenl  S  must  surely  be  linked  with  that  of  a  language, 
or  possibly  a  family  of  languages,  that  are  capable  of  harnessing  its  full  power.  So  those 
languages  must  now  be  considered  an  important  part  of  the  TenlS  world,  and  had  better  be 
good. 

Uitfortunately,  as  well  as  gaining  syntactic  power,  the  present  notation  has  garnered  a  large 
range  of  non-orthogonal  historic  encrustations  which  must  be  cleaned  away.  We  started 
prodticing  a  new  compiler  which  reformed  the  worst  of  these,  like  the  module  system.  Strict 
upward  compatibility  was  not  required,  but  we  did  wish  to  salvage  as  much  existing  code  as 
possible.  Excepting  system  problems,  this  new  compiler  is  largely  complete.  For  the  future 
we  will  have  to  consider  the  functionality,  style  and  power  we  want  from  new  languages. 

Work  items: 

evolution  to  extend  scope  of  language  support 
complete  new  notation  compiler 
consider  expressiveness  of  a  new  language 
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6  Conclusion 

TenlS  addresses  a  large  number  of  problems  in  computing,  particularly  in  the  fields  of  data 
integrity  and  systeitts  progranuning,  which  are  outside  the  remit  of  TDF.  Nevertheless,  in 
many  respects  its  structure  and  functionality  is  inadequate.  Given  sufficient  time  and 
resources  TenlS  could  no  doubt  have  been  extended  to  cover  a  much  broader  spectrum  of 
programming  styles  and  architectures,  and  to  do  so  with  greater  ease  and  assurance  than  it 
presently  does. 

The  review  of  the  inadequacies  and  suggested  extensions  presented  in  this  paper  is  wide 
ranging,  and  the  effort  it  implies  is  very  high.  The  language  rteeds  to  be  cortsidered  as  a 
whole;  piecemeal  extensioru,  for  example  the  facilities  for  parallelism  added  by  the  COOTS 
team,  occlude  the  real  goals  of  the  project.  Inirthermore,  technical  problems  were  being 
encountered  in  building  the  demonstration  systerrt  Consequent  upon  the  lack  of  necessary 
resources  the  development  of  TenlS  along  that  path  was  abandoned. 

We  believe  that  future  work  programmes  will  adopt  the  ideas  of  TenlS.  In  this  docunnent,  we 
have  discussed  weaknesses  in  its  defittition,  and  consequences,  both  positive  and  negative, 
resulting  from  its  all-embracing  approach.  Recognition  of  these  aspects  will  help  future  teams 
to  identify  specific  problems  for  investigation.  To  this  extent,  at  least,  the  TenlS  experience 
has  been  valuable. 
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